1. Field of the Invention
The invention generally relates to the field of computer modeling and the corresponding constraint language, and particularly relates to a method and constraint language editor for generating model-related constraint expressions.
2. Description of Related Art
Computer modeling, especially software modeling, mainly refers to object modeling in the field of software engineering, such as Unified Modeling Language (UML) and Eclipse Modeling Framework (EMF). It describes an application program at a higher level, so that the implementation codes of the application program can be generated in part or entirely. Most models are composed of a plurality of block and arrow diagrams and the accompanying texts. Information expressed by such models is incomplete, informal, and inaccurate, sometimes even self-contradictory. A number of deficiencies in a model are caused by the limited expression ability of the utilized diagrams. Sometimes, some conditional statements cannot be expressed by diagrams only, although the statements should have been apart of a complete specification. For example, if the UML modeling is performed on the relationship between a flight and passengers, the association between a flight and passengers may represent that the passengers of a flight can be a certain group. Such a one-to-many association is a multirelation, which means that the number of passengers is infinite. Actually, however, the number of passengers can not exceed the number of seats of the plane servicing this flight. Nevertheless, such a constraint cannot be expressed on a UML diagram. Here it is necessary to attach a constraint language therein, such as Object Constraint Language (OCL), Schematron, etc.
Taking OCL as an example, in the OCL specification, it is mentioned that: A UML diagram, such as a class diagram, is typically not refined enough to provide all the relevant aspects of a specification. There is, among other things, a need to describe additional constraints about the objects in the model. Such constraints are often described in natural language. Practice has shown that this will result in ambiguities. In order to write unambiguous constraints, so-called formal languages have been developed. The disadvantage of traditional formal languages is that they are usable to persons with a strong mathematical background, but difficult for the average business or system modeler to use. OCL has been developed to fill this gap. It is a formal language that remains easy to read and write. OCL supports UML by providing expressions, which have neither ambiguity of natural languages nor inherent difficulty in using complex mathematical expressions.
Using expressions written by a mathematics-based, accurate language, such as OCL, provides a number of additional advantages for a system model expressed by a diagram, for example, such expressions will not be construed as different meanings by different roles (such as an analyzer and a programmer). They are explicit and make the model more accurate and detailed. The expressions can also be checked by some automated tools to ensure they are correct and consistent with other elements in the model, so that the code generation becomes more effective. However, the model described simply by means of expressions is often hard to understand. For example, although source codes can be considered as an ultimate model of software, most people would like to see a diagrammatic model when dealing with a system at the first time. An advantage of line, block and arrow diagrams is that the meaning may be easy to understand. For software developers, combining and utilizing UML and OCL brings out the best in each other. A large number of different diagrams and OCL expressions can be combined to express a model. It is noted that for a complete model, the diagrams and expressions are indispensable. Without OCL expressions, the model may be not consummate enough; without UML diagrams, the OCL expressions may reference an element model that does not exist—since there is no mechanism in OCL to represent class and association. Therefore, a model can be expressed completely only by combining diagrams and constraints.
Four features of OCL are introduced in detail in Jos Warmer, Anneke Kleppe “Object Constraint Language, Getting Your Models Ready for MDA, Second Edition”.
1. OCL is Both a Query Language and a Constraint Language.
A constraint is a restriction on one or more values of (part of) an object-oriented model or system. All values in a UML class diagram can be constrained, and the way to express these constraints is OCL. In the UML 2 standard, not only used for writing constraints, OCL is also used for writing expressions for any elements in a UML diagram. Each OCL expression can direct to a value or an object in the system. Since OCL expressions can derive any value or a set of values in a system, it has the same ability as SQL.
2. OCL is Mathematics-Based, but Uses No Mathematical Symbol.
The foundation of OCL is the set theory and predication logic in mathematics, and OCL has a formal mathematical semantic. It, however, does not use a certain type of mathematical symbols. The reason is that although mathematical symbols can express things explicitly and unambiguously, they can be read only by just a few experts. Mathematical symbols are therefore not suitable for a widely-used standard language. Natural language is most understandable, but is unclear and indistinct and cannot be handled by computers automatically. OCL takes a compromise between natural language and mathematical symbols, which expresses the same concepts as in mathematics by utilizing conventional ASCII characters. If you do not like the current OCL expression method, the OCL specification also allows you to define your own OCL symbol set. This is reasonable, since OCL has an explicit mathematical semantic.
3. Strong Typed Language
OCL is a typed language. The values of any expressions are belonging to the same type. This type can be a predefined standard type, such as Boolean or Integer, or elements in a UML diagram, such as objects, or a set of these elements, such as a set of objects, a package, an ordered set, etc.
4. Declarative Language
What is opposite with respect to declarative language is procedural language. A procedural language, such as Java, is a kind of programming language, which describes steps of performing actions. In a declarative language, however, its expressions only describe “what” to do rather than “how” to do. In order to guarantee this, OCL expressions have no side effect, i.e. calculating the value of an OCL expression will not influence the system status at all.
Since OCL is a declarative language for describing rules applied to UML models, expressions in UML are advanced to the field of pure modeling, without paying attention to the implementation details and implementation languages. Expressions define values of a system at a higher abstract level, thereby preserving the accuracy of 100%. OCL is also a navigation language for graph-based models, but the text expressions for constraints are complex. The constraint expressions are in the form of text, so that a user can only write them with the knowledge of the syntax structure. A user, however, is usually not familiar with these constraint languages, so that writing expressions by them may take a great effort with a poor quality. Current OCL editors only have limited support for expression generation, wherein there is no navigation expression editing for complex meta-models. Furthermore, an expression designer must face OCL syntax in addition to meta-models. The term “navigation” will be described in detail hereinbelow.
Typical OCL editors mainly focus on the constraint syntax, thus causing very bad user experience. A user needs to face a text-based constraint editing user interface. The user still needs to know the OCL syntax to write expressions, although the editor can help user complete expressions automatically in part, for example, in current OCL editors, after the user selects an element, he can only be prompted the attributes and methods of the element and the direct association elements.
FIG. 1 illustrates an exemplary diagram of an SQL Statement Editor (RAD). In the figure, RAD provides a “model-level” view and frees user from the burden of SQL statement editing. Namely, a user only needs to perform model editing without worrying about the SQL syntax. After the user finishes model design, the SQL syntax will be generated automatically by the application. In prior art, however, there is no similar tool for automatically generating OCL expressions for UML/EMF.
Schematron (standing for XQuery, XPath, XSLT) and OCL can provide comparable constraint semantic but in different syntaxes. In prior art, there is no uniform tool to support both types of language editing. For example, referring to FIG. 2, an example is shown of two different constraint syntaxes sharing the same model and constraint semantics. FIG. 2 is a particular instance about navigation. The top half of the figure is used for describing the instance of application program deployment, in which the designer likes to add a constraint that the name of the database connected to the data source DataSourceUnit of WAS 6.0 AppServer (WAS is abbreviation of WebSphere Application Server) is equal to “tradedb”. Namely, the constraint semantic is that the data source requires that the connected database is tradeDB. Starting from the data source DataSourceUnit, the constraint needs to navigate to its connected database (DB2 8.1 Database), next to the name of the database, and finally it is required that the name is equal to “tradedb”. The navigation process in the figure is from the element DB2Database/DB2 Database (201) to the element DB2 Database (202), and the solid arrow connecting 201 and 202 is navigation. The semantic can be implemented by several different syntaxes, such as OCL expressions and Schematron expressions. In the bottom half of the figure, the constraint is expressed by two constraint languages, OCL and Schematron, respectively. The navigation-related parts in the expressions are marked by black blocks, wherein, the OCL expression in block 210 and the Schematron expression in block 220 are necessary for navigation. It can be seen that in a complete constraint expression, the navigation expression occupies a majority of space. While writing constraint expressions, a user needs to find a navigation method/association in a complete element list provided by the editor, and needs to perform type conversion manually. This requires many steps, thus the navigation helping becomes particularly important. In current editors, helping for navigation is not provided, and a user needs to implement a navigation path step-by-step. Moreover, some valid navigation paths may not be provided. Therefore, there is a need for a novel technology for extracting constraint semantic, providing navigation helping, and generating different constraint codes for different syntaxes.